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Abstract 


Signal  and  Data  Processors  are  the  sub-assemblies  which  are  the  most  likely  obsolescent  parts  in  modern  airborne 
Radars.  As  their  architecture  is  based  on  multiple  parallel  COTS  processors,  the  implementation  of  the  algorithms  in 
these  processors  is  a costly  and  time  consuming  task  which  represents  the  most  significant  part  of  the  cost  when  the 
sub-assembly  has  to  be  replaced  due  to  component  obsolescence. 

The  use  of  a powerful  software  workshop  is  the  way  to  dramatically  cut  the  cost  of  the  software  redesign  by  an 
extended  re-use  policy. 

A significant  improvement  in  the  radar  development  cycle  can  be  achieved  through  simulation  techniques.  These  new 
tools  and  methodology  enables  to  reduce  costs  and  to  shorten  the  radar  modes  development  cycle. 

During  the  phase  of  specification,  a functional  radar  prototype  is  developed,  requirements  are  defined,  and  testing 
procedures  are  developed.  This  functional  radar  prototype  is  completely  independent  of  the  processor  hardware  and 
survives  to  COTS  obsolescence. 

During  the  phase  of  on-board  functional  software  development,  the  functional  prototype  is  re-used  to  simulate  the 
machine  architecture  (processors  in  parallel,  communications,  ...)  and  the  algorithms  are  optimized  for  the  target 
processor  hardware. 

During  the  testing  phase,  a cross  test  between  the  functional  prototype  and  the  on-board  functional  software  can  be 
performed  by  the  re-use  of  the  testing  procedures.  Also,  the  flight  tests  can  be  prepared  by  the  simulation  of  the  scenario 
to  be  played. 

The  designer  can  be  assisted  by  a tools  for  all  this  developments. 


L Introduction 


New  radars  or  new  radar  modes  become  more  and  more  complex.  The  sophisticated  signal  processing  algorithms  and 
the  real  time  requirements  need  multiple  processors  machines.  To  reduce  the  cost  of  radar  development,  to  shorten 
development  cycles,  and  to  cope  with  obsolescence  problems  of  the  processor  hardware,  a new  methodology  based  on 
simulation  and  re-use  of  simulation  software  is  applied  in  THOMSON-CSF  DETEXIS  for  some  years. 

The  main  means  of  this  new  methodology  are: 

further  use  of  simulation  techniques  in  the  phases  of  system  specification  and  design, 
re-use  of  simulation  software  modules  in  embedded  software, 
set  up  of  two  workshops  (simulation  and  processing  machines). 

In  a classical  approach,  4 distinct  software  were  developed: 

advanced  studies  software  to  design  algorithms, 
function  modelling  software  for  radar  design, 
applicative  software, 

data  analysis  software  to  process  in-flight  recorded  data. 


Paper  presented  at  the  RTO  SCI  Symposium  on  "Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components",  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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The  new  approach  consists  in  re-using  a same  software  for  different  tasks.  In  fact,  3 out  of  these  4 software  run  on  a 
host  machine  (work  station);  the  software  used  for  prototyping  the  radar  can  be  exactly  the  same  as  the  software  for 
analyzing  the  in-flight  recorded  data.  The  software  for  advanced  studies  can  be  re-used  for  the  radar  design.  So,  on  the 
host  machine  (workstation),  we  can  have  a single  software  (or  a re-use  of  code).  This  software  being  completely 
independent  of  the  hardware,  it  is  not  affected  by  obsolescence.  For  on-board  software,  the  problem  is  quite  different  : 
this  software  runs  on  a target  processor  which  implies  a lot  of  constraints.  The  solution  is  to  re-use  the  software  running 
on  the  workstation  for  assisting  the  designer  to  develop  the  on-board  software  : source  code  can  be  re-used. 

To  illustrate  the  simulation,  we  can  consider  a 3 phases  development  cycle:  specification,  on-board  software 
development,  and  validation. 


2.  Virtual  prototyping 

During  the  specification  phase,  simulation  can  be  used  for  prototyping  the  virtual  radar  on  an  host  machine 
(workstation).  This  radar  prototype  allows  to: 

• design  the  functionality  of  the  radar  mode  and  to  define  the  interfaces  between  the  different  modules  of  the 
radar, 

• specify  the  exact  algorithm  which  is  needed  (to  avoid  overspecification), 

• evaluate  the  radar  performance,  such  as  resolution  for  an  air  to  ground  mode  or  detection  range  for  an  air 
to  air  mode, 

• and  finally  define  the  validation  procedures.  The  prototype  software  is  verified  with  these  testing 
procedures,  which  are  the  functional  reference  for  the  radar  mode.  These  procedures  will  be  re-used  at  the 
validation  phase. 

This  virtual  prototype  is  independent  of  the  hardware  technology  and  is  represents  the  “reference”  of  the  radar. 

Then  the  designer  can  be  assisted  by  a tool  for  the  development  of  the  radar  prototype  software:  a tool  (such  as 
Ptolemy)  can  facilitate  the  designer’s  work.  A toolbox  is  created  with  a library  containing  signal  and  data  processing 
algorithms.  The  designer  can  build  the  prototype  and  takes  each  algorithm  he  needs  from  the  toolbox  and  then  links 
together  the  algorithms  with  a specific  tool.  Then  on  workstation,  final  output  or  intermediate  output  can  be  verified. 
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EXAMPLE  OF  FUNCTIONAL  MODEL  DESIGNED  WITH  PTOLEMY 
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Example  of  functional  model  with  the  tool  Ptolemy 


3.  On-board  software  development  (new  hardware  design  1 

The  second  main  phase  of  a radar  mode  development  is  the  on-board  software  development.  With  the  virtual  prototype, 
a signal  and  data  processing  software  is  available;  this  software  runs  on  workstation  (single  processor  environment).  At 
the  end  of  this  phase,  the  on-board  software  must  run  on  a multi-processors  machine.  To  re-use  the  virtual  prototype 
software,  the  methodology  is  as  followed: 

• in  a first  phase,  a model,  matched  to  the  processor  architecture,  is  developed  on  the  basis  of  the  functional 
model,  taking  into  account  the  architecture  and  the  characteristics  of  the  machine. 

• in  a second  phase,  each  algorithm  is  compiled  and  optimized  for  the  target  processor.  For  each  algorithm, 
the  number  of  cycles  and  the  memory  size  must  be  known.  This  is  possible  if  the  processor  accepts 
algorithm  in  a language  such  as  C or  C++,  . . .which  is  the  case  of  new  COTS  DSP  or  processor. 

• In  a third  phase,  the  software  is  linked  and  loaded  in  the  target  machine  and  can  be  verified  on  the  test 
bench. 

This  methodology  is  of  interest  also  because  it  enables  the  designer  to  disconnect  the  problems  : the  algorithm  problems 
are  seen  during  the  functional  model  development;  the  parallelism,  memory  mapping  or  communication  problems  are 
seen  during  the  development  phase  of  the  model  matched  to  the  target  architecture.  When  working  on  the  hardware  test 
bench,  all  these  problems  are  solved  and  the  designer  can  concentrate  on  real-time  problems. 

The  designer  can  be  assisted  by  tools  to  optimize  the  algorithms  implementation  on  processors.  For  example,  a tool  can 
measure  the  workload  ratio  for  each  processor  or  evaluate  time  for  data  processing  . Some  tools  also  generate  the  source 
code  for  each  processor  and  software  for  communication  between  processors  or  between  the  different  memories  of  a 
processor. 
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FUNCTIONAL  SIMULATION  WORSHOP 


The  different  phases  of  the  on-board  software  development 


4.  Validation 


The  third  main  phase  of  a development  cycle  is  the  validation.  During  this  phase  the  testing  procedures,  defined  at  the 
specification  phase  (and  run  on  the  functional  prototype  on  workstation),  are  played  on  the  radar  on  the  test  bench,  and 
the  both  results  can  be  compared.  By  that  way,  the  functional  requirements  can  be  verified. 

Always  in  the  phase  of  validation,  simulation  techniques  can  be  used  for  assisting  flight  tests. 

• The  scenario  that  will  be  played  in  flight  can  be  played  first  on  the  virtual  prototype  on  the  host  machine.  So,  flight 
tests  can  be  prepared,  and  results  can  be  analysed. 

• Simulation  techniques  allow  evaluation  and  validation  in  a complex  environment.  For  example  it  is  possible  to  add 
on  recorded  data,  some  synthetic  data:  targets,  jammers... 


5.  Conclusion 


In  conclusion,  using  simulation  techniques  all  along  the  development  cycle  enables  to  design  the  functional  prototype  of 
the  radar  which  is  the  reference  of  the  radar  architecture,  modes  and  algorithms.  As  this  reference  is  not  technology 
dependant,  it  can  be  re-used  when  the  hardware  has  to  be  upgraded  minimising  the  redesign  and  validation  cost.  On  the 
other  hand,  libraries  of  algorithms,  subassembly  models  and  workshops  can  be  re-used  for  new  radar  product 
developments  to  design  the  new  functional  prototype.  It  also  helps  the  designer  to  develop  the  on-board  software,  to  do 
cross-testing  between  the  functional  prototype  and  the  on-board  software,  and  finally  to  prepare  the  flight  trials. 

A cost  saving  (and  time  saving)  by  a factor  2 to  3 has  already  be  demonstrated  either  for  new  developments  or  for 
processor  upgrades. 


